Clinical diagnostic tests are commonly used in the medical profession to assist in diagnosing various medical conditions of a patient. Clinical diagnostic tests refer to those tests where a laboratory conducts an analysis on a specimen/sample from a patient. The term “sample” or “specimen” as used herein is intended to refer to such substances taken from a body including, without limitation, blood, urine, tissue, saliva, or other body substances. Following analysis of the patient sample, the laboratory produces a test result. The test result is then used by the doctor or other medical professional to assist in the diagnosis of one or more medical conditions.
In addition to clinical diagnostic testing, specimens may also be analyzed in other environments, such as pre-clinical testing. Pre-clinical testing refers to situations where drugs or devices are tested in a laboratory setting using various samples. For example, a new drug may be administered to a patient, and the patient's blood may be monitored to determine the effects of the drug on the patient. The term “clinical test result” as used herein is intended to refer to test results produced from clinical diagnostic testing and/or pre-clinical testing.
In a hospital lab, a test order for a clinical diagnostic test is delivered from a doctor and received in the laboratory accompanied by a patient sample. The patient sample is analyzed on one or more laboratory instruments to obtain test results. Examples of laboratory analyzers used to analyze patient samples include flow cytometers, hematology analyzers, immunoassay analyzers, and electrophoresis analyzers. It will also be recognized that numerous other laboratory analyzers may be used to analyze patient samples. Furthermore, manual testing may also be performed on the sample by a laboratory technician to provide test results for the test order. Once a sample is analyzed in the laboratory, the fulfilled test order is sent back to the doctor in the form of a test result. In many environments, the test order is received electronically and the test results are reported electronically through a local area network which provides access to various information systems.
The release of actual test results from the clinical diagnostic laboratory is typically staged. In particular, “raw” test results from the laboratory analyzer are typically held in the laboratory's own database and computer system, often referred to as the laboratory information system (“LIS”). These raw test results are typically not released for viewing outside of the laboratory until they are approved by the lab. As mentioned above, raw test results may be approved automatically or manually following review by a lab technician. Once test results are approved, the test results are released to a hospital or other medical facility's database and computer system, often referred to as the hospital information system (“HIS”). Doctors and other care providers have access to the approved test results in the HIS, but only the laboratory staff has access to unapproved results in the LIS.
Accordingly, one task for the laboratory technician performing or overseeing clinical diagnostic tests is to validate the test results obtained from the laboratory analyzers or from manual testing before they are released to various information systems. The need for validation is present because many problems can occur during the sample gathering and testing process. For example, a patient sample may be mislabeled, resulting in test results being reported in association with the wrong patient. As another example, the patient sample may have been improperly drawn or improperly handled, resulting in sample contamination and erroneous test results. Furthermore, a laboratory analyzer may be either malfunctioning or drifting out of calibration, again causing the analyzer to report erroneous results.
Abnormal test results do not necessarily indicate erroneous results, but may instead indicate a serious medical problem. In such cases, it may be important for the lab technician to report the test results immediately to the doctor or other medical professional in addition to the normal reporting procedure of making the test results electronically available through a database. In these situations, the test results indicating a critical condition may call for the lab technician to make an immediate and confirmed report to the doctor, such as by telephone or in person.
Evaluating test results can, in many cases, be done automatically by a computer. This process of using a computer to automatically evaluate laboratory test results is called autoverification (or autovalidation). Using autoverification, a test result from a laboratory analyzer is sent to a computer for evaluation. If the computer determines that the test result meets predetermined criteria established by the laboratory, the test result is approved and automatically released to the doctor. Test results that fail autoverification are held for manual review by the lab technician. Upon manual review, the lab technician may decide upon certain actions, such as releasing the test result, calling for a new test, calling for a new patient sample, calling for service on the laboratory analyzer, requesting confirmation of input data, or various other actions.
Existing laboratory information systems attempt to provide autoverification capabilities by having the user write a series of “if/then” rules that are evaluated by the computer when test orders are received, test results are obtained, and/or results are uploaded to the HIS. These if/then rules essentially amount to a text-based programming language where the user is expected to write the complete autoverification process with the provided language. However, laboratory technicians are not typically trained in computer programming skills and find it difficult to write the autoverification rules based on the common text-based language. In addition, even for accomplished programmers, the provided language is typically awkward, and it is easy for the programmer to neglect certain aspects of the desired autoverification rule which is displayed as a confusing list of textual statements. Furthermore, once an autoverification process is defined using such systems, it is difficult for a laboratory technician to pull the defined autoverification process at a later time and easily determine the workflow within the process, since the series of textual “if/then” statements are difficult to follow. Accordingly, it would be advantageous to provide an autoverification system where autoverification processes created using the system are easily defined by the user and quickly and easily understood when presented to the user at a later time.
In addition to the awkward language used to define autoverification rules, existing systems also do not assist the technician in checking the correctness of autoverification rules. Before autoverification rules are used in the laboratory, they are typically hand checked to determine if the rules are correct and will operate as expected. In order to determine if an autoverification rule is correct, a lab tech will provide several example inputs, and work through the autoverification rule to arrive at a result based on the example input. The user must then decide whether the rule provides an unexpected result based on the example input. If an unexpected result is obtained, this indicates a potential problem with the autoverification rule as defined. This process of hand checking autoverification rules is tedious and subject to human error, as the lab technician works through the autoverification rule one example input at a time. In particular, if the user does not follow the rule precisely, the outcome determined by the user for a particular rule check may be entirely different than the actual outcome under the rule. Accordingly, it would be advantageous to provide a system for testing autoverification rules that is accomplished automatically, thus relieving the laboratory technician of the burden of manually checking autoverification rules while also providing a systematic process for rule testing.
Another problem with current rule checking processes is the difficulty in confirming that all possible steps through the rule have been checked. With the current rule checking processes, it is easy for the lab technician to forget about certain steps within the autoverification rule and forget to provide and test example inputs that move through these steps. Accordingly, it would be advantageous to provide a system for testing autoverification rules that includes a tool for ensuring that all possible steps through the defined autoverification rule have been tested.
Furthermore, if an autoverification rule is modified following initial rule checking, current systems provide no support for regression testing of the rule. In other words, when an autoverification rule is modified, no tools are provided to assist the user in seeing different outcomes based on the changes to the rule. This means that all previous rule checking for a particular autoverification rule must be redone whenever there is a modification to the rule. Accordingly, it would be advantageous to provide a system for testing autoverification rules that includes a tool for retesting a modified rule without the need to completely redo the original rule testing.
Yet another need with current systems for testing autoverification rules is the ability to easily document rule testing. In many laboratories, rule checking is mandatory before the rule may be used in the laboratory. With current systems, hand written notes are the only available proof of rule checking. Therefore, it would be advantageous to provide a system for testing autoverification rules where the testing procedure may be easily documented, thus providing proof that the autoverification rules have been properly tested.